Purpose
  • To create a user-interface prototype.
Steps

For each use-case storyboard to be prototyped in the current iteration, perform the following steps:

Note that these steps are presented here in a logical order, but it is likely that you will need to alternate between them, and perform them in parallel. Initially, you spend the most time designing the prototype; then, after a while when you know more about the prototype, you spend the most time implementing it and getting feedback on it.
Input Artifacts: Resulting Artifacts:
Worker: User-Interface Designer

Workflow Details:


Design the User-Interface Prototype To top of page

The following are different aspects of designing the user-interface prototype:

These aspects are presented below. However, a project need not consider all of these aspects in the prototype. Instead, it can often be appropriate to leave some aspects to the implementers and thus not deal with them in the prototype. In this case, we recommend that you leave the lower aspects in the list, and focus on the upper aspects.

While you design the prototype, you should:

Identify the Primary Windows

Each boundary class aggregate yields a candidate for a primary window in the user interface. However, recall that one of the goals when building the object model was to identify as shallow aggregation hierarchies as possible; the purpose of this was essentially to minimize the number of primary windows and thereby also the window navigation paths required between them. In addition to adding needless interaction overhead, window navigation paths that are too long make it more likely that the user will "get lost" in the system. Ideally, all windows should be opened from a main primary window, resulting in a maximum window navigation length of two. Try to avoid window navigation lengths greater than three.

The main primary window should be the window that is opened when the user launches the application. It is normally always open as long as the application is running, and is the place where the user spends a considerable part of his "use time." Since it is always open and since it constitutes the user's first contact with the system, it is the foremost vehicle for enforcing the user's mental model of the system.

The most obvious candidate for the main primary window is defined by the top boundary class of the aggregation hierarchy, for example the Document class in a document editor. For details, refer to Guidelines: Boundary Class. If there are several aggregation hierarchies, choose the one that is most important to the user, that is, where the major part of the use time is spent.

When the main primary window is identified, you should consider the other aggregate classes that are part of the aggregation hierarchies, and decide whether or not they should be designed as primary windows. The default recommendation is that they should be designed as composites instead of primary windows of their own, if possible. Again, this is to minimize the number of primary windows and thereby also the window navigation paths required between them. Moreover, a composite is often justified by the fact that its constituents need to be shown together, and in spatial relation to, the constituents of other composites; note that this is hard to achieve if (primary) windows are used instead.

Example:

The Paragraph aggregate in a document editor is designed as a composite instead of a primary window of its own. This is partly because the constituents of a Paragraph, i.e. Characters, should be shown together, and in spatial relation to, the Characters of other Paragraphs.

As an alternative design, imagine the usability of a document editor where the user had to navigate to a separate (primary) window each time the contents of a specific paragraph is to be viewed.

However, it is often the case that all aggregates cannot be designed as composites, due to limitations in screen area. If there is not room for designing all aggregates as composites, try at least to design the following aggregates as composites:

  • The aggregates that are central to the user's mental model of the system.
  • The aggregates that the user will spend most use time in.
  • The aggregates that provide the initiation of use cases.

Note that the average object volumes is an important input to this step, since they state how many objects that potentially need to be shown at once. Too many objects may imply that they cannot be designed as composites; instead, they may have a compact representation in the primary window in which they reside, and then define primary windows of their own.

Design the Visualization of the Primary Windows

The visualization of the primary windows, and the main primary window in particular, will have a significant impact on the usability of the system. Designing this visualization means partly that you have to look at what parts (attributes) of the contained objects should be visualized; the flow of events - storyboard descriptions, and especially when extended with the desired guidance needed, will help you prioritize which attributes to show. If the user need to see many different attributes of the objects, you may implement several views of a primary window, each view visualizing a different set of attributes. Designing this visualization also means that you have to look at how the parts (attributes) of the contained objects should be visualized, by using all visual dimensions. For details, refer to section "Visual Dimensions" in Guidelines: User Interface (General).

If a primary window contains objects of several different classes, it is important to find "common denominators" for these classes, for example. attribute types that are contained in all or most classes. By visualizing common denominators by some dimension, the user can relate objects of the different classes with each other and start to see patterns. This greatly increases the "bandwidth" of the user interface.

Example:

Assume you have a customer service system, where you want to show aspects like:

  • The customer's complaints and questions over time.

  • What products the customer has purchased over time.

  • How much the customer has been invoiced over time.

Here, a common denominator is "time." Thus, displaying complaints/questions, purchases and invoices beside each other on the same horizontal time axis will enable the user to see patterns of how these are related (if they are).

Design the Operations of the Primary Windows

The responsibilities of the boundary classes specify the operations required by their corresponding windows. It is common that the operations of the primary windows and their contained objects are provided as menu items in a menu bar, and are provided as an alternative and complement via shortcut menus and toolbars. If a primary window contains objects of several classes, and these have different operations, you can assign one menu for each class, or one menu for each group of cohesive operations.

Example:

In a document editor, there is an Edit menu, grouping cohesive operations such as Cut, Copy, etc.

Note also that some operations may require a complex interaction with the user, thereby justifying a secondary window of their own.

Example:

In a document editor, there is a Print operation on a Document that, due to its complex interaction, justifies a separate dialog window.

Design the Property Windows

Property windows need to be designed for all boundary classes, thereby making all their attributes available to the user. Note that some objects may only be partly visualized when they reside within a primary window (see the section "Design the Visualization of the Primary Windows" above); their property windows will, on the other hand, visualize all their attributes. Note that any average attribute values are an important input to this step, since they help in deciding the optimal visualization of a specific attribute.

Some of the simple responsibilities of boundary classes, such as setting the value of a specific attribute, are often provided as an operation by the property window. Such an operation is then either unavailable in the primary window in which the object resides, or it can work as an alternative or complement to a similar operation in the primary window.

Also, if a boundary class is part of an association, this association (including the associated objects) is normally visualized in the property window.

Design the Operations Involving Multiple Objects

If a boundary class defines a large number of objects to be visualized in the user interface, it is often delicate to design operations involving these objects. The following are different variants of such operations:

Design Miscellaneous Features

Add the necessary dynamic behavior to the user interface. Most dynamics are given by the target platform, like the select-operate paradigm, open by double clicking, pop-up menus on right mouse button, etc. There are, however, some decisions you need to make, including:

  • How to support window management. Refer to section "Window Management" in Guidelines: User Interface (General).
  • What session information, like input cursor position, scroll bar position, opened windows, window sizes, relative window positions, etc., to store between sessions. Refer to section "Session Information" in Guidelines: User Interface (General).
  • Whether to support single or multiple document interfaces (SDI or MDI) for your primary windows.

Also evaluate other common features that can enhance usability, including:

  • Whether "on-line help," including "wizards," should be provided. Refer to section "On-line Help" in Guidelines: User Interface (General).
  • Whether an "undo" operation should be provided, to make the system safe for exploration. Refer to section "Undo" in Guidelines: User Interface (General).
  • Whether "agents" should be provided, to monitor user events and actively suggest actions. Refer to section "Macro Agent" in Guidelines: User Interface (General).
  • Whether "dynamic highlighting" should be provided, to visualize associations. Refer to section "Dynamic Highlighting" in Guidelines: User Interface (General).
  • Whether user-defined "macros" should be supported.
  • Whether there are specific areas that should be user configurable.

Implement the User-Interface Prototype To top of page

There are basically three kinds of implementations of a user-interface prototype:

  • Drawings: created by the use of pencil and paper.
  • Bitmaps: created in a bitmap editor.
  • Executables: mock-up applications that can "run" and interact with end-users.

In most projects, you should use all three kinds of implementations, in the order listed above. This order allows for the simple incorporation of changes early on, since their typical implementation times differ greatly (drawings are much faster to create and modify than executables). However, drawings do not properly reflect limited screen area; it is easy to put more in a drawing than there is room for on the screen.

The best way to finally specify the user interface is through a combination of bitmaps and executables. This should be done as soon as you need to expose the prototype to people other than user-interface designers. A bitmap can specify the exact look of the primary windows, whereas the executables can approximate the look of the primary windows and support their operations, as well as the looks and behavior of the secondary windows. Naturally, if you can implement the exact looks of the primary windows in the executable, with a reasonable effort, this is better than combining the executable with a bitmap. If you don't have enough resources to produce an executable, you can use bitmaps as the final implementation of the prototype. In this case, it can be useful to complement them with use-case storyboards describing their dynamics; otherwise, chances are high that the implementers of the user interface will get the dynamics wrong.

Note that the focus should not be on achieving a good structure and modularization of the source code for the executable prototype; instead, the focus should be on creating a throw-away prototype that visualizes the significant aspects of the user interface and that provides some of its significant operations. Moreover, a prototype is likely to change several times when it is designed and exposed to others, and these changes are often made as cheap patches. As a result, the source code of the prototype is often of very limited value, and not "evolutionary," when the real user interface is to be implemented.

In general, it is of value that an executable prototype is cheaper to implement than an implementation of the real user interface. The following are some differences between the prototype and the real implementation of the user interface:

  • The prototype need not support all use cases and scenarios. Instead, only a small number of use cases and/or scenarios may be prioritized and supported by the prototype.
  • The primary windows are often the most complicated to implement; if you make an advanced user interface that really takes advantage of the visualization potential, then it may be difficult to find ready-made components. Rather than implementing new components, you can normally use primitive components, such as push-, toggle- or option buttons, as an approximation of how the user interface will look for a certain set of data. If possible, make several prototypes showing different sets of data that cover the average values and object volumes.
  • Simulate, or ignore, all operations on windows that are non-trivial to implement.
  • Simulate, or ignore, the internals of the system, such as business logic, secondary storage, multiple processes, and interaction with other systems.

Get Feedback on the User-Interface Prototype To top of page

It is immensely important to expose the user-interface prototype to others. But, to get valuable feedback, you don't have to go through full-blown use tests where real users perform real tasks with the prototype. Most things you find in use tests are just flaws, caused by "home blindness" that anyone who wasn't involved in the user-interface design could have told you.

As the design and implementation of the prototype progresses, you expose the design to increasing numbers of reviewers, including:

  • other project members
  • external usability experts
  • users

Exposing the Design to Other Project Members

This is an underestimated way of exposing the design. It has a very fast turnaround time: project members are already familiar with the application, and they are usually very available for a spontaneous demo. Do this continuously during the activity, to cure your own "home blindness."

Exposing the Design to External Usability Experts

A good usability expert can decrease development efforts by pointing out obvious usability flaws based on his skills and possibly different perspective of the user interface. It can thus be of value to involve external usability experts during the first half of the activity, so you have time to work in the new direction, as suggested by the usability experts.

Exposing the Design to Users

Making demos for users is usually good use of your time. Do this as often as you can (access to users is often limited), to correct misperceptions made during requirements capture. However, don't expose the prototype to users before you have at least a decent bitmap prototype of the main primary window. And don't expose the same user to the prototype more than once; the second time, the user will be tainted by your earlier design ideas (similar to "home blindness").

Also, be careful to set the expectations right. Many users will want to have the right behavior behind the user interface, i.e. the windows, when the system is built.

How to Expose the Prototype

The best way of exposing a prototype is often to sit together with the person you expose it to, in front of a screen showing the prototype. Walk through a common scenario, for example, a use case's normal flow with normal values, as described in a use-case storyboard. Encourage the person to ask questions and give comments. Take notes.

Another, rather overestimated, way of exposing the design is to perform use tests. In a use test, real users perform real tasks with the prototype. The problem with this is that to get reliable results:

  • You must have a very "ready" prototype, almost as functioning as the final user interface. When you have reached this far in development, it is usually too expensive to make significant changes.
  • You will have to sufficiently train the user. Most users will be "improving intermediates"; if you want to test how good the prototype is for these users, you will have to train them, in the worst case for several weeks.

Because of these reasons, and if you don't have a very generous budget for creating the user interface, use tests should, at the most, be done at the end of the iteration in which the (parts of the) user interface is created.



Copyright  ⌐ 1987 - 2000 Rational Software Corporation

Display Rational Unified Process using frames

Rational Unified Process